1. The Field of the Invention
The present invention relates to distributed applications and, more particularly, to mapping between object oriented and service oriented representations of a distributed application.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. As a result, many tasks performed at a computer system (e.g., voice communication, accessing electronic mail, controlling home electronics, Web browsing, and printing documents) include the exchange of electronic messages between a number of computer systems and/or other electronic devices via wired and/or wireless computer networks.
Networks have in fact become so prolific that a simple network-enabled computing system may communicate with any one of millions of other computing systems spread throughout the globe over a conglomeration of networks often referred to as the “Internet”. Such computing systems may include desktop, laptop, or tablet personal computers; Personal Digital Assistants (PDAs); telephones; or any other computer or device capable of communicating over a digital network.
In order to communicate over a network, one computing system (referred to herein as a “sending computing system”) constructs or otherwise accesses an electronic message and transmits the electronic message over a network to another computing system (referred to herein as a “receiving computing system”). The electronic message may be read by a human user as when the electronic message is an e-mail or instant message, or may be read, instead, by an application running on the receiving computing system. The electronic message may be constructed by an application running on the sending computing system with the possible assistance of a human user.
In some environments, such as, for example, a service oriented architecture environment, connection endpoints (often and hereinafter referred to as “services”) communicate with one another to implement desired functionality. Desired functionality can be as simple as two services exchanging data. For example, a service consumer can send a service request message to a service provider. The service provider processes the service request and returns a service response message to the service consumer. However, desired functionality can also be more complex involving a number of services exchanging messages to coordinate some activity. A service typically has some type of computer system (both hardware and software) that supports the connection endpoints.
Service oriented concept descriptions (addresses, bindings, and message interaction patterns) can be used to describe a service. The service oriented concept descriptions can then be accessed by service consumers that desire to communicate the described service. Generally, service oriented concepts are described in accordance with some service oriented standard, such as, for example, Distributed Component Object Model (“DCOM”), Common Object Request Broker Architecture (“CORBA”), or Web services. Web services can be further defined in accordance with various Web services specifications, such as, for example, Web Services Description Language (“WSDL”), Web Services Policy Framework (“WS-Policy”), etc.
Thus, a service provider can describe a service using WSDL. On a Local Area Network (“LAN”) or possibly even between known interconnected networks, the service provider can publish the description to a directory of services, for example, that uses Universal Description, Discovery, and Integration (“UDDI”). An aware service consumer with access to the directory can issue queries against the directory to locate a WSDL service description. Portions of the WSDL service description published by the service provider can be passed on to the service consumer in response to a query. The service consumer uses the portions of the WSDL service description to send appropriately formatted requests to the service provider. In turn, the service provider provides an appropriate response to the service consumer.
However, to implement a service in accordance with a specified service oriented concept description, there must be executable modules that process messages as described in the service oriented concept description. Thus, a developer typically writes source code (e.g., in an object oriented language, such as C#, C++, or Visual Basic) to implement message processing for the service as described in the service oriented concept description. The source code can then be compiled into an executable module (e.g., a dynamic link library) and executed, for example, as a server runtime, to provide the service to service consumers.
Unfortunately, services can utilize different programming models that implement distributed messaging functionality in different ways. For example, one programming model can implement a request message using one interface and a corresponding reply message using a second different interface. On the other hand, another programming model can implement both a request message and a corresponding reply message using a single interface that has separate methods. The single interface can have one method for the request message and a second different method for the corresponding reply message. Thus, services based on different programming models typically cannot communicate with one another.
Further, distributed applications are typically rigid in their programming models allowing only one programming model that is tightly coupled to their service runtime. Accordingly, for compatibility, a client runtime (e.g., at a service consumer) is also typically required to process messages in accordance with the programming model used to develop a corresponding service runtime. For example, if a service runtime was developed using separate interfaces for request and reply messages and using particular security mechanisms, the client runtime must implement those as well. Failure to use a client runtime developed in accordance with the same programming model can prevent a client runtime from communicating with a service runtime.
Unfortunately, there is always some chance that no service description has been published for a service runtime. Further, even when a service description has been published, a client may be unaware that the published service description exists, or may be prevented (e.g., by security mechanisms or network conditions) from accessing the published service description. On larger distributed networks, such as, for example, the Internet, the chances of such difficulties occurring substantially increase. Thus, it may be difficult, if not impossible, to implement a client runtime in accordance with the appropriate programming model. As a result, the client may be prevented from communicating with a server runtime.
Therefore systems, methods, and computer program products for accessing a service description in other ways would be advantageous.